Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/644

Internet Message Format | 1994-08-27 | 6.8 KB

Date: Tue, 14 Jun 1994 21:40:24 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Digest
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9406142124.A15873-0100000@undergrad>
Mime-Version: 1.0
Precedence: bulk


Ofir:
---------------
In message <[e-mail]>,
[e-mail] said:
>
><arrow left>    hide block, put cursor at left end
><arrow right>   hide block, put cursor at right end

OK.
---------------
Keep in mind that these are only useful for systems where the block is
considered to be a "big cursor".  Since I like this system, I agree with
the above, but  let's not muddle the systems.  If you're going to use
big-cursor, good, but if you're not, don't confuse people.  There is
another distinct system (although not well standardized, where the block
is entirely independant of the cursor, and using the arrow keys does
nothing more than move the cursor around.

Ofir:
------------------
>> CTRL I -                 Show Info
>
>In text oriented applications I prefer CTRL-I  italic

This was in my original proposal but was removed, maybe I should put it
back then.

>It could be used alternatively depending on the type of application.
>
>CTRL-B -           bold
------------------
This is a tough issue.  Block operations are more frequently used than
are formatting operations (I would suppose), so the block operations
should be assigned first.  Ctrl-B/E should therefore take presidence.
However, under a big-cursor system, selecting a block would not quite be
done by the Ctrl-B/E way.  More involvement with the mouse or use of
Right-Shift in the manner of Windows would have to be done.  In this
case, you could use Ctrl-B for Bold and Ctrl-E for something else.
Someone suggested using the Ctrl or Alt number keys for text attributes.
While this wouldn't be very mnemonic, it WOULD put the attributes on the
keyboard SOMEWHERE, and if everyone used it, people would learn it.

As for Ctrl-I, I think both are good.  How about allow text apps use it
for Italic, and others for Show Info.  On the other hand, if you use the
number keys, then stick with Show Info.

Ofir:
---------------
>
>Alt Del -              Delete to end of line
>Alt BS -               Delete from start of line

Since many people have asked me to change this, I propose to make an
exception and use the Alt key for this shortcut.
---------------
Yes, Yes, Yes!  Thank you, thank you, thank you!

Shift Delete and BS should only each delete one character just as the
unshifted versions.


Michel Forget:
--------------
This is not the case at all; under a multitasking system, some programs
will write directly to the console.  That will screw up the screen and
no redraw messages will be sent to the application.  It is not the
fault of the application, yet the screen is still messed up.  To date,
though, MultiTOS, Geneva, and Mag!X all have a way to redraw the entire
screen (so these keypresses are not needed).  Still, it is not a good
idea to assume that the screen is always going to be perfect looking.
---------------

In the editor for ANSITerm, if you want to call it that, I did, in fact,
assign something to Ctrl-A.  It redraws the displays, because this
editor, if you want to call it that, is not designed to be able to do
much very well, so it will often not properly update the screen.  As a
result, whenever I hit Ctrl-A by accident, it goes virtually unnoticed.

So, how about we do the same?  Ctrl-A == Redraw screen.  Something easy
to hit has something totally harmless assigned to it.  Normally, I
wouldn't suggest this since I would assign something freqently used and
very productive to key combinations that are easy to hit, but, as I've
pointed out, Ctrl-A is TOO easy to hit, and therefore, if anything at all
is assigned to it, it should be totally harmless, and what could be more
harmless than Redraw window?


Vincent:
---------------
I prefer:
  home -           nothing
  shift + home -   move to top of doc
  ctrl + home -    move to bottom of doc
because "home" is near the arrows (partially between up-arrow and
right-arrow) and can be hit by mistake.
---------------
I partially agree.  I have accidentally hit home before, and it was
annoying, but it was not destructive.  As long as what Home does isn't
DANGEROUS, it may be okay to use it.


Vincent:
------------------
> However, is the Windows-like "delete a block when typing something new",
> something we need to consider when dealing with this group of
shortcuts? Or
> should we in general recommend that a block can only be deleted explicitly,
> preferably with a Ctrl-Delete?

I prefer the ctrl-delete solution. Moreover, typing text shouldn't deselect
the block.
------------------
As I've said before, doing this results in an abandonment of a system of
handling block that is not only well-accepted, but also one that requires
less work than alternatives.  Nevertheless, in situations where you must
have a heterogenous command set, there SHOULD be a distinction between
block and text operations.  Delete should delete a single character, and
something else should delete the block.  Since Ctrl-Delete is already
assigned to delete-next-word, it is not a good choice.  Since
Shift-delete has been de-assigned, and delete to end of line been
assigned to Alt-Delete, then Shift-delete should be used for delete
block.  However, whatever you do, do not assign anything but delete a
single character to Shift-Backspace (we know why), and Shift-delete
should delete only one character when no block is selected.


Christian:
---------------
I think standardisation is more important than free definition by the user
because the majority of users won't bother to redefine shortcuts, and this
will also be less accepted by programmers if they have to include code.
Even I am not sure if I will support this in papyrus. Reassigning shortcuts
is also problematic because in some apps the keyboard is almost full with
shortcuts, so by redefining one is likely to loose a shortcut for an
app-specific function - actually it is unpredictable what will happen when
it is used. That brings me to different idea:
---------------
I agree with this.  First and foremost, define the STANDARD, THEN think
about ways of making it configurable.  I know that MANY programmers won't
want to put in any code to handle configuration of shortcuts (their code
or not... I'm seldom able to compile someone else's code without
modification, and I can never read it.).  Face it, people are either too
busy or lazy.  Either way, only a fraction of apps will support the
config file.





You know one things that's missing from RSC files?  The ability to put
code into the resource file.  Could be useful.  Of course, it would also
be nice to have a C++ compiler with English docs.